Publish your Form
Publishing a form involves converting your Digitise Forms project into the required files for your website, deploying these files to the website and creating any required databases.
Form Studio can publish your forms to a local website on the same machine or to a remote web server.
If your project contains more than one form, all the forms in the project will be published.
The Digitise Forms website files are split into two components:
The Client files are the files which will be displayed in the browser and comprise HTML5, JavaScript and CSS.
The Client files can be deployed to the same website as the Forms Server files (see below) or they can be published to a folder from where they can be manually deployed to a different website, allowing you to host the Client files on a different web server to the Server files, e.g. a non-IIS web server or one in a different domain.
The Server files are compiled program files which handle data requests from the Client and are responsible for all communications with your SQL Server databases, thus removing database access from the browser.
The Forms Server files must be deployed to a Microsoft IIS website.
Digitise Forms uses Web Deploy to assist in publishing your forms. Web Deploy is a Microsoft tool designed to simplify deploying and managing IIS websites. When you publish a form, Form Studio creates a Web Deploy deployment package, containing the Client and Server files, which is used to automatically deploy your form to your chosen website for you. Web Deploy v3.6 is required on both your development PCs and on any IIS web servers to which you want to deploy forms. This utility should have been installed by the Digitise Forms setup, but if not, you can download Web Deploy free of charge from Microsoft's website. At the time of writing it was available here.
To publish the forms in your current project, choose File ➝ Publish. The Publish screen will be displayed. The first time you load the Publish screen within a project it will look like this:
You must create a Publishing Profile before you can publish your project for the first time. Changes to a Profile are saved automatically.
A Publishing Profile contains the information Form Studio needs to publish your form(s), including web server address, website to use and connection strings for your Datasources and the Digitise Forms configuration and logging databases.
You will need to create a Publishing Profile to specify your configuration settings before you can publish your form(s) for the first time. Thereafter, when you want to publish your form(s) using the same configuration, you can simply select the Profile and publish, you don't need to re-enter the information all over again. If you want to publish form(s) using different configuration settings, you can create different Profiles for each group of settings. For example, you could create different Profiles for your test, development and live environments allowing you to publish to different websites and provide different database connection strings for each one, preventing you having to specify these details each time you want to publish the form(s).
To create a new Publishing Profile, click on 
to display the following menu:
Empty
Creates a new empty profile. Use this option if you want to publish your form(s) to a remote web server.
Localhost
Creates a new profile for use when publishing your form(s) to your local machine.
Choose the appropriate option from the menu to create your new Profile and display the Profile settings.
To delete a Publishing Profile, select the Profile in the Profile drop-down list at the top of the Publish screen and then click 
.
When you create a new Profile, the Profile settings will be displayed. Once you have created at least one Profile, when you load the Publish screen the last used Profile will automatically be selected and its settings will be displayed. The Profile settings will look something like this:
If this is a new Profile you can now configure the settings.
If you want to change an existing Profile, select the required Profile in the Profile drop-down list at the top of the screen if it isn't already selected. The Profile's configuration settings will be displayed and you can then edit them.
Specify a name of your choice to identify this Profile.
Enter the IP Address or DNS name of the web server you want to publish to. This should be the address used to access the web server internally within your organisation. If you are publishing to your local machine, you can specify localhost, 127.0.0.1, the computer name or the full computer name.
If this is a new Empty Profile, when you replace the default text displayed in this option, '<server>', and then move to a different option, the Server URL option (see below) will automatically be populated with a default URL based on the DNS Name/IP Address entered here. Subsequent changes to the destination web server's DNS name/IP Address will not update the Server URL option again, so that if you edit the Server URL option, changes to the Destination IIS Server DNS Name option will not overwrite your Server URL changes. This is because the name/address you use to access the web server internally within your organisation may be different to that which is used for access from outside the organisation.
If this is a new Localhost Profile, this option will automatically be set to localhost.
This option is only displayed if you are publishing to a remote web server and allows you to specify what type of authentication you want to use to access IIS on the remote machine.
If IIS has been configured to allow you to connect using your current Windows credentials, select Use current Windows user credentials.
Alternatively, if you will be connecting using an IIS user configured within IIS, you should select Use IIS Manager credentials. Selecting this option will display additional Username and Password fields, allowing you to enter the required IIS User credentials.
This option is not relevant if you are publishing to your local machine.
The name of the IIS website to which you want to publish your forms. By default this is set to use the Default Web Site. If you want to publish to a different website, enter the name of the website here. A web application will be created in your chosen website to contain the form(s) in the current project.
If you are publishing your form(s) to a remote web server, the website you specify here must already exist, it will not be created during the publish.
Enter a name for the web application to contain your form. By default, Digitise Forms will use the project name for the web application, but you can use a different name if you prefer. Note, however, that if you specify a name here which has already been used for another web application, the existing web application will be overwritten.
The web application specified here will be created in the website specified in the Website option above.
The name you enter here is automatically used to create the default Server and Client URLs. Changes you make to the web app name will be reflected in the Server and Client URLs, unless the Serve client from a different domain option (see below) is selected, in which case changes to the web app name will only affect the Server URL and will not be reflected in the Client URL.
If you save your project to a new name, existing profiles won't be updated with the new name and you will have to manually edit this option to reflect the new name if required.
Enter the URL of the web application hosting the Forms Server component, e.g. https://<web server name>/<path>/<web app name>. The Digitise Forms Client component will use this URL to communicate with the Forms Server component.
The DNS name/IP Address/Machine name included in this URL should be the public-facing address and may be different from that entered in the Destination IIS Server DNS Name option above, e.g. where you use different DNS names to access the website internally and externally.
-
When you start a new Empty Profile, the Destination IIS Server DNS Name option (see above) displays the default text '<server>'. When you replace this with the DNS name/IP Address of your web server and then move to a different option, the Server URL option is automatically populated with a default URL based on the DNS Name/IP Address of the web server entered in the Destination IIS Server DNS Name field and the web app name entered in the Website Application field. The URL will start with 'https:'.
Subsequent changes to the destination web server's DNS name/IP Address will not update the Server URL option again, so that if you edit the Server URL option, changes to the Destination IIS Server DNS Name option will not overwrite your Server URL changes. This is because the name/address you use to access the web server internally within your organisation may be different to that which is used for access from outside the organisation.
Changes to the web app name, however, will update the Server URL.
If you start a new localhost Profile, the Destination IIS Server DNS Name option will use the default name localhost instead and the Server URL option is automatically populated with a default URL of http://localhost/<web app name>. Note, that in this case the URL starts with 'http:' rather than 'https:'. As with remote web server profiles, subsequent changes to the Destination IIS Server DNS Name option won't change the value specified in the Server URL option but changes to the Website Application option will.
If you save your project to a new name, existing profiles won't be updated with the new name and you will have to manually edit this option to reflect the new name if required.
Select this option if you want to deploy the Client and Server components of your form to different web domains, e.g. if you want to host them on different machines or under different websites.
If you select this option, when you publish your project, the Client files will be created in a folder you specify (see the Alternative Website Client Path option below) and won't be added to the deployment package or deployed to your website. You will need to manually deploy the files from the specified folder to the required website. The Server component, however, will be added to the deployment package and will be deployed to the website you specified above.
- If you deploy your Client and Server components to different web domains, you should be aware that initial security data passed between them has to be contained within a query string of a URL, as it cannot be passed in the same way as it is when they are in the same domain. This potentially makes this information more vulnerable to attackers. However, the data is included in a strongly encrypted format and doesn't compromise the intended level of security, which is designed to withstand this happening.
If the option is not selected, the Client files will be included in a web deploy package generated by the publish and will be deployed to your website, along with the Server component.
Selecting this option will display the following additional options:
Enter the URL of the Digitise Forms Client component web app, e.g. https://<web server name>/<path>/<web app name>. The Forms Server will only process data for requests coming from the URL you enter here.
The DNS name/IP Address/Machine name included in this URL should be the public-facing address and must match exactly the DNS name/IP Address/Machine name used in the URL users will use to load the form in their browsers. It may be different from that entered in the Destination IIS Server DNS Name option above, e.g. where you use different DNS names to access the website internally within your organisation and externally from users' browsers.
By default, this option will be given the same value as that entered in the Server URL option (see above), and will start with 'https:' if you are publishing to a remote web server or 'http:' if you are publishing to your local machine. If the Serve client from a different domain option is NOT selected, changes to the Server URL will automatically be applied to the Client URL. If Serve client from a different domain is selected, changes to the Server URL will NOT be applied to the Client URL.
This option allows you to specify the folder to which the Client files should be published instead of being included in the deployment package. You will have to manually deploy the files created here to your chosen website.
To enter or change the folder, you need to use the Browse button to the right of the option, you can't type in a folder path. This is to prevent you selecting a folder which doesn't exist or entering invalid characters. Clicking the button will load a standard Windows file browse dialog box. Locate and select the required folder and then choose the Select Folder button.
This option lists all the forms in your project and allows you to specify whether you want a PDF copy of each form to be produced when the form is submitted. The form can be submitted when the user clicks or taps the form's Submit button or the Pay button in the Capita Pay360 Cart Element, if the Cart is configured to submit the form on payment.
You can adjust the width of the columns in the Forms category table by clicking and dragging the column heading boundaries.
Displays the name of the form. You can't edit this field.
Displays the URL of the form. This is the URL that a user will enter into their browser to access the form. You can't edit this field.
The form URL is automatically created based on the values in the Server URL, Client URL and Website Application fields together with the name of the form. The URL will start with 'https:' if you are publishing to a remote web server or 'http:' if you are hosting the form on your local machine. If the URL is too long to be visible, you can either change the width of the column, by clicking and dragging the column border within the header row, or hover your mouse pointer over the URL to display the full value in a tooltip.
If the Serve client from a different domain option is NOT selected, the Server URL is combined with the web app name and the form name to create the form URL. Changes to the Server URL and Website Application fields will be reflected in the form URL.
If the Serve client from a different domain option is selected, the form URL is created by combining the Client URL with the name of the form. Changes to the Client URL will be reflected in the form URL, but changes to the Server URL or web app name will have no effect on the form URL.
- As you can't edit the form URL, you can't make changes to the default URL directly. If Serve client from a different domain is selected, you can change the Client URL option and this will automatically update the form URL. However, if Serve client from a different domain is not selected and you want to change the form URL, you can temporarily select Serve client from a different domain allowing you to make the required change in the Client URL option. This will update the form URL and then you can deselect Serve client from a different domain again.
If you save your project to a new name, existing profiles won't be updated with the new name and you will have to manually edit this option to reflect the new name if required.
This option allows you to set a limit on the number of API requests which can be made to the Digitise Forms Server component. An API request is a request to the Digitise Forms Server to perform an action such as a Datasource upload or download, a file upload or adding an entry to the client log. Normally, these requests will be legitimate requests from the web pages which make up a form but allowing you to set a limit provides protection from malicious attackers attempting to instigate a Denial of Service (DoS) or other attack against your form.
The API request limit is specified separately for each form and the default number of API requests is 100 per form.
When deciding on the level to set this at, you will need to bear in mind how many API requests you think is reasonable for a user to make whilst using the form. You will need to consider such things as how complex your form is, whether you expect users to move backwards and forwards through your form, your Dataset usage, the number of records which are likely to be submitted, your use of Events and so on. Each Dataset download and update and each record uploaded will involve separate API requests. Note that a Dataset marked to load with the form is actually loaded when the page on which its data is first used is displayed and if a user returns to this page the Dataset will be called again and hence generate another API request each time the page is displayed. Consider also that a form submission may include multiple records, e.g. if you have used a Recordset Element on your form. If you switch client logging on, you will need to allow for a much higher limit, since the logging can generate a large number of API requests.
We would suggest you add a small number on top of what you think you might need, say add 5 or 10, and generally recommend you exceed what you think you'll need comfortably. If you are familiar with using browsers' Dev Tools, you can get a good idea of how many API requests are likely to be needed by checking in the Dev Tools whilst running your published form.
This option provides an overall limit for all APIs but you can also set individual limits on the number of read and write requests that can be made to individual Datasets, within each Dataset's properties. This allows you to provide lower limits for individual Datasets than would be available if they just relied on the value specified here in the Max APIs option. Any limits set at the Dataset level are still subject to the overall limit specified in Max APIs.
At runtime the server will return an HTTP 429 error code if the user hits the API limit. You can check for this error in the browser's standard Dev Tools' console or network tabs and if you have Server Logging switched on, an error message will be added to the log.
The limit set here remains active from the time a form is loaded until its session expires, which by default is about an hour. Closing the browser tab or window doesn't end the session. If you attempt to use the form once the session has expired, API requests to the Digitise Forms Server component will fail with HTTP 401 errors.
If you select this option, when the form is submitted, a copy of the completed form will either be produced as a PDF file and written to the folder specified in the PDF Folder option below, or saved as a record within the NDLFXPDF database using the Save PDF to DB option - see below.
The form can be submitted when the user clicks or taps the form's Submit button, the submitForm function is called within custom JavaScript or the user clicks or taps the Pay button in the Capita Pay360 Cart Element, if the Cart is configured to submit the form on payment.
By default, the option is not selected and a PDF copy will not be produced.
If you want to produce PDF copies of the completed form, you must generate a template before you attempt to publish the form.
This option is not relevant to the use of Imported Stored Procedures where the Stored Procedure returns a Result Set, and won't include Elements used to provide or display data for these Stored Procedures.
If you select this option, when creating a PDF copy of the form (see Create PDF on submit option above), the URL of the created PDF file will be returned to the Client for use in your own custom JavaScript.
By default, the option is not selected and the URL will not be returned.
When you select this option, the PDF will be saved to the NDLFXPDF database, rather than to a folder, as described below. Note that when this option is chosen, a new connection string for the NDLFXPDF database will appear beneath the Datasources heading (see the Datasources section, below), but this won't be visible if this option hasn't previously been selected. For more information, see the Save PDFs to a SQL Database section of the Create PDF Copies of Completed Forms topic.
Allows you to specify the folder in which to store PDF copies of the form, if you include PDF generation within your form, either by selecting the Create PDF on submit property (see above) or by including a Get PDF Button Element on your form.
You can either type in the path of a folder on the machine hosting your form's Forms Server component, e.g. C:\Digitise Forms\MyPDFs, or use the browse button, 
, to the right to display a standard browse dialog allowing you to locate and select your required folder.
If you are typing in the path for your folder, you can specify a folder relative to the root folder of the form's IIS web application by prefixing the path with ./, e.g. ./MyPDFs would represent C:\inetpub\wwwroot\<web app name>\MyPDFs if you have published your form to the Default Web Site. If you have selected the Return PDF URL option above, you must specify a relative folder.
-
If you specify a subfolder below the form's IIS web application folder, such as the default ./PDFs folder, this folder will be deleted with all its contents whenever you republish the form. We, therefore, recommend that you specify a permanent folder, which is valid for the machine hosting your form's Digitise Forms server components and is outside the web application folders.
If you specify a folder outside the web application folders, your PDF files will not be deleted by Digitise Forms, and will remain there. You may, therefore, want to regularly check and, if required, clear out the folder as part of your standard housekeeping procedures.
-
You will need to make sure that the user under which your web app runs has write permissions for the folder you specify. If your web app is running under the ApplicationPoolIdentity user refer to the FAQs for information on giving this user access to your specified folder.
-
If you want to store your PDFs to a remote network drive rather than on the machine hosting your web app, you should create a service account under which to run your web app, and not use the ApplicationPoolIdentity user, and you must specify the PDF folder as a UNC path, e.g. \\MyPC.myco.com\MyPDFs, using a shared drive and not a mapped drive. You must then give this account change permissions to your chosen folder.
This option allows you to configure a path where uploaded files will be stored. In previous version of Digitise Forms, uploaded files were saved to a Fileuploads folder which was overwritten whenever a form was re-published. This meant that any files that you wished to keep had to be copied from within the Fileuploads folder then pasted back into it again after the next re-publish. See the File Upload element topic for more details.
This option allows you to incorporate Google Analytics into your form. Google Analytics is an independent service supplied by Google which provides you with a mechanism to collect and analyse data about how your web apps are used.
In order to use Google Analytics you must have a Google Analytics account - see Diagnostic and Audit Logging and Analytics for more information.
This option allows you to incorporate standard Google Analytics usage into your form by specifying the Google Analytics Tracking ID for the Google Analytics property to which you want form usage data to be sent.
If you enter a Tracking ID here, a standard segment of code, with your Tracking ID inserted in the appropriate places, will be added to your form's index.html file, to load and configure the Google Analytics global site tag library. Then, whenever a user loads your form, information about how they use the form will be sent to the Google Analytics service.
Alternatively, if you want to customise your Google Analytics usage, you can provide your own HTML/JavaScript code snippet in the GA Code Snippet option below. If you enter a value in the GA Code Snippet option, any value entered here in the GA Tracking ID option will be ignored.
To remove Google Analytics from your form, clear the GA Tracking ID and GA Code Snippet options and republish the form.
This option allows you to incorporate Google Analytics into your form. Google Analytics is an independent service supplied by Google which provides you with a mechanism to collect and analyse data about how your web apps are used.
In order to use Google Analytics you must have a Google Analytics account - see Diagnostic and Audit Logging and Analytics for more information.
This option allows you to provide an HTML/JavaScript code snippet to be added to the HTML generated for your form. The code snippet will load and configure the Google Analytics global site tag library, causing information about how users use your form to be sent to the Google Analytics service for later analysis and evaluation.
The code snippet must be complete, including containing your Google Analytics Tracking ID in the appropriate places. The snippet will be inserted, without any modifications, into the index.html file for your form.
This option allows you to supply your own tailored version of the code required to use Google Analytics within your form, e.g. if you need to link domains or have multiple Google Analytics properties to which you want to send the data. To add your code snippet, simply copy and paste the snippet into the text box here in the GA Code Snippet option.
If you don't need to customise your Google Analytics usage, you can use a standard code snippet instead, by entering your Google Analytics Tracking ID in the GA Tracking ID option above. If you enter a code snippet here in the GA Code Snippet option, any value entered in the GA Tracking ID option is ignored.
To remove Google Analytics from your form, clear the GA Tracking ID and GA Code Snippet options and republish the form.
These options allows you to configure the connection strings for all the SQL Server databases connected with this project. All the relevant databases are listed here and for each one you can specify the required connection string.
For Imported Datasources, the connection string specified when the database was imported to the project will be displayed here. You can, however, change the connection string if necessary, e.g. to use a test database rather than a live database.
For Digitise Forms Datasources, you can specify the connection string to be used to create and access the database. By default, we recommend that you store all Digitise Forms Datasources in the Project Datasource.
For the NDLFXPDF datasource, the connection string specified will be used when the Save PDF to DB option beneath the Forms heading has been selected. If you haven't previously selected the Save PDF to DB option, a connection string for the NDLFXPDF database won't be visible. If, on the other hand, you select and then de-select the Save PDF to DB option, the connection string for the NDLFXPDF database will appear and will remain visible even if you are no longer saving the PDF to the SQL database. See the Create PDF Copies of Completed Forms topic for more information.
Passwords within the connection strings are displayed here as a series of asterisks, '*', to prevent them being read by unauthorised people.
Displays the name of the Datasource. You can't edit this field.
The Connection column displays the current connection strings for your Datasources and allows you to edit them.
To specify or change a connection string, click on the browse button, , in the relevant row for the Datasource you want to modify. The SQL Database Connection dialog will be displayed, allowing you to specify or edit the connection string for that Datasource.
If you specify Windows Authentication as the method of logging in to the SQL Server in the connection string, when you try to publish your project an error message will be displayed in the Publisher validation dialog box and the publish will fail.
If you really do want to use Windows Authentication to access the SQL Server, select this option to prevent the error message appearing and the publish failing.
Note, if you do want to use Windows Authentication to access a SQL database, you will need to make sure that the database has been configured to allow suitable access to the user under which your web site will be running.
To find out which user your web site is running under:
Load Internet Information Services (IIS) Manager on the PC hosting your website.
Expand the tree in the Connections Pane on the left-hand side of the window.
Find your web application in the tree and click on the website it comes under to select the website.
Click on Basic Settings... in the menu down the right-hand edge of the window.
Make a note of the name displayed in the Application Pool field.
Click Cancel to close the dialog.
Select the Applications Pools node at the top of the tree, immediately below the machine name.
Select the Application Pool you noted earlier.
Click on Advanced Settings... in the menu down the right-hand edge of the window.
Under the Process Model category, find the Identity property.
This property tells you the user that will need permissions to access the database.
This option controls the appearance of form elements within the form PDF. In order for elements to appear for a particular Datasource, the Store Request Data check box included in the Datasource row needs to be selected. If the check box is deselected, elements mapped to that Datasource will not be visible, even if those elements have been configured to appear using the Is Visible in PDF option (which can be found in the Value box on the Data tab within the Properties pane when an element has been selected). In order for items to appear within the PDF, both Store Request Data and Is Visible in PDF need to be selected.
These options allow you to enable and specify Content-Security-Policy (CSP) headers for your form to help protect against possible Cross Site Scripting (XSS) and other attacks. XSS attacks involve a third-party attempting to inject malicious scripts into a web app, in this case your form. CSP headers allow you to provide trusted locations from which legitimate external resources can be loaded by your form, e.g. when using one of the map Elements or Google Analytics, and thus preventing malicious scripts from a non-trusted location from being run.
- CSP headers incorrectly specified can prevent your form from functioning correctly. We recommend that you only change the CSP headers if you know what you are doing and that you test your form in a test environment before publishing to a live environment.
Allows you to turn CSP headers on and off within your form. Selecting this option will enable the headers, which means that they will be included within your form, and will display the other CSP options below this option on the Publish page. Deselecting the option will disable CSP headers, so they won't be included in your form's web pages and the other CSP headers options, described below, will be hidden.
By default, the option is NOT selected and CSP headers are disabled.
This option is only displayed if you have enabled CSP Headers in the Enable Content-Security-Policy headers option above. It allows you to disable any CSP header values displayed in the table below (see Required Source Values below). This can be used where you want to specify your own custom values for the headers and you don't need any of the values added by Digitise Forms.
This column lists the CSP directives which may be added to your form if CSP headers are enabled in the Enable Content-Security-Policy headers option above. You cannot change the values displayed here.
The table displaying CSP Header values is only displayed if you have enabled CSP Headers in the Enable Content-Security-Policy headers option.
The table displaying the CSP header values is only displayed if you have enabled CSP Headers in the Enable Content-Security-Policy headers option above.
The Required Sources Values column displays CSP header values which are required in order for your form to function correctly if CSP headers are enabled. Form Studio will automatically add required source values here if you add a Google Maps, Bing Maps or Address Finder Element or Google Analytics to your form, since all these require access to external resources to operate. If there are no required values and you don't enter any custom values (see below), an empty CSP header will be added to your form.
The values displayed here can be disabled using the Disable required CSP source values option, above. Selecting this option will cause Digitise Forms to ignore the required values and only include any custom values you add (see below). However, be aware that disabling the required values may stop your form from working as expected.
The table displaying the CSP header values is only displayed if you have enabled CSP Headers in the Enable Content-Security-Policy headers option above.
The Custom Source Values column allows you to enter your own CSP values to be used alongside, or instead of, any required values displayed in the Required Source Values column.
Each row in the column consists of a text box, allowing you to enter your required values for the directive displayed at the beginning of the row. You can type in and edit your values in the standard manner.
Values entered here will be included in the CSP headers and added to your form, if CSP headers are enabled in the Enable Content-Security-Policy headers option above.
Allows you to specify the connection string to be used to access the Digitise Forms Configuration Database. The Configuration Database is used by the Forms Server component to store information about your forms, configuration settings and logging messages (if logging to database is enabled). The default name for this database is NDLFXDB, although you can use a different name if you prefer.
Whichever name you choose, Digitise Forms will automatically add a version number to the end in the format ##Digitise Formsnn, where nn is a number representing the configuration version number, e.g. NDLFXDB##FX01. When specifying the database name in the connection string, you can include this suffix or leave it off, as Digitise Forms automatically deals with the versioning, but in the connection string field here the versioning is displayed.
To enter or change the connection string, click on the browse button, . Refer to the
Passwords within the connection strings are displayed here as a series of asterisks, '*', to prevent them being read by unauthorised people.
- The connection string entered here will be stored, encrypted, in the web application's FXWebApp.xml file. In previous versions of Digitise Forms, the connection string information was stored in plain text within the web application's web.config file. This required manual encryption (after publishing) using Microsoft's protected configuration provided within its .NET framework software. This is now no longer necessary.
If you specify Windows Authentication as the method of logging in to the SQL Server in the Configuration database connection option, when you try to publish your project an error message will be displayed in the Publisher validation dialog box and the publish will fail.
If you really do want to use Windows Authentication to access the SQL Server, select this option to prevent the error message appearing and the publish failing.
Note, if you do want to use Windows Authentication to access a SQL database, you will need to make sure that the database has been configured to allow suitable access to the user under which your web site will be running. If you need help to check which user your web site is running under, see the Can Use Windows Authentication property under the Datasources category above.
Allows you to specify the connection string for the database you want to use to store Forms Server logging. Click on the browse button, , to enter or change the connection string. Refer to the
Generally, the connection string entered here will be the same as that in the Configuration database connection option above, but you can specify a different SQL Server instance and/or database for audit and diagnostic logging if you prefer.
Whatever database name you choose, Digitise Forms will automatically add a version number to the end in the format ##Digitise Formsnn, where nn is a number representing the configuration version number, e.g. NDLFXDB##FX01. When specifying the database name in the connection string, you can include this suffix or leave it off, as Digitise Forms automatically deals with the versioning, but in the connection string field here the versioning is displayed.
Passwords within the connection strings are displayed here as a series of asterisks, '*', to prevent them being read by unauthorised people.
- The connection string entered here will be stored, encrypted, in the web application's FXWebApp.xml file. In previous versions of Digitise Forms, the connection string information was stored in plain text within the web application's web.config file. This required manual encryption (after publishing) using Microsoft's protected configuration provided within its .NET framework software. This is now no longer necessary.
If you specify Windows Authentication as the method of logging in to the SQL Server in the Logging database connection option, when you try to publish your project an error message will be displayed in the Publisher validation dialog box and the publish will fail.
If you really do want to use Windows Authentication to access the SQL Server, select this option to prevent the error message appearing and the publish failing.
Note, if you do want to use Windows Authentication to access a SQL database, you will need to make sure that the database has been configured to allow suitable access to the user under which your web site will be running. To check which user your web site is running under, see the Can Use Windows Authentication property under the Datasources category above.
Allows you to specify a folder to use as the root folder for the web application created in IIS by the Digitise Forms publisher, if you don't want to use the standard folder. This option is only relevant when you are publishing your project to your local machine. To specify the folder you want to use, click on 
to display a standard browse dialog allowing you to locate and select the required folder.
If you leave this option blank, the publisher will automatically specify the folder for you. If you loaded Form Studio using the Run as administrator option, the folder specified will have the same name as your project and will be located below the website specified at the top of the Publish options. If you are not running Form Studio as administrator, Digitise Forms won't have permission to create your web app under the website, and will use the following folder instead:
C:\ProgramData\NDLFXWebApps\<project name>
If you save your project to a new name, existing profiles won't be updated with the new name and you will have to manually change this option to reflect the new name if required.
If this option is selected, the Digitise Forms publisher will run Web Deploy to generate the deployment package and to deploy your form(s) to your IIS website.
If not selected, the Web Deploy package will be created but will not be deployed to the website. By default, the package will be created in the following folder:
C:\Users\<username>\Documents\NDL Software\Form Studio\Publish\
<project name>\<publishing profile name>
but you can change this using the Publish path option below, if necessary.
Note that the deployment package is retained until you publish the project again, when it will be overwritten by the new package.
If this option is selected, when you publish your project, the Digitise Forms publisher will simulate a publish but does not actually deploy your form(s). It generates a report detailing what would happen if you had deployed the form(s) so that you can check for errors etc.
To view the generated report, you can either select the Review deployment feedback option below, which will automatically display the report when the simulated deployment has finished, or you can manually open the report file:
C:\Users\<username>\Documents\NDL Software\Form Studio\Publish\
<project name>\<publishing profile name>\Webdeploy.txt
This option allows you to take a backup of your project before it is published. By default, the option is selected, which means that Form Studio will save a backup of the project before publishing. If you deselect the option, a backup will not be stored before the publish.
Publish backups are saved to a separate folder under the project folder:
C:\Users\<username>\Documents\NDL Software\Form Studio\Projects\<project name>\Backups\
<publishing profile name>\<project name>_<version no>_<date>_<time>
The version number is assigned by Form Studio, starting with 1.0.0.1, and is automatically incremented each time the project is published and a backup is stored. The latest Project version number can be found on the Info page accessible from the File Menu. The Info page also tells you the number of times the project has been published in the Publish count, which includes times when the project is published without saving a backup first.
Within the backup folders, the name of the project file, identified by its '.fxproj' file extension, will also have the version number, date and time appended to the original file name.
If you want to restore a backup you will need to manually copy the files from the backup folder back into a project folder. You can either copy the files to the original project folder or create a new project folder for them. If you are copying the files to the original folder, remember to take a backup of the current files before you do so, if you might want to be able to restore the current project later.
By default, the original folder will be called:
C:\Users\<username>\Documents\NDL Software\Form Studio\Projects\<project name>
If you overwrite your existing project files in this way, you will probably want to edit the project file name to remove the versioning and timing information appended to the name by the backup process.
If you want to create a new project folder you can copy the required backup folder to the Projects folder, by default:
C:\Users\<username>\Documents\NDL Software\Form Studio\Projects
and then edit the folder and project file names if you want to remove the versioning and timing data appended to the names and to distinguish this project from the original one. When you open the project in Form Studio you will see that it still has its original project name. Use the Save As option to change the name and save the project back into its current folder.
Backup folders are not deleted by the Form Studio.
Review deployment feedback
If this option is selected, when the publish has completed, Form Studio will open Windows Notepad and display the Web Deploy log file which tells you what happened during the publish.
Specifies a folder to be used to initially generate the files required for your form and from where Web Deploy will deploy the form to the web site. By default this folder is:
C:\Users\<username>\Documents\NDL Software\Form Studio\Publish\
<publishing profile name>
The Publish path option allows you to change this folder should you need to.
You may want to change the folder path here if you are publishing a project previously published by another developer and their username is being used within the folder path rather than yours.
Note that Digitise Forms does not delete the files after publishing.
You can type in the full path of the folder or click on the Browse button, , to display a standard browse dialog allowing you to locate and select the required folder. You cannot enter a UNC file path here, but you can use mapped drives instead.
If you don't enter a full path name, Digitise Forms will use your Digitise Forms installation folder as its starting point and attempt to create your specified path below that. By default Digitise Forms is installed under Program Files (x86) which requires you to be running Form Studio as administrator in order for the Studio to be able to create folders and write files. Therefore, if you don't enter a full path and don't run Form Studio as administrator, the publish will be unable to write to your specified folder and the publish will fail.
If you save your project to a new name, existing profiles won't be updated with the new name and you will have to manually edit this option to reflect the new name if required.
Once you have a suitably configured Profile you can publish your project.
If you want to publish your project using an existing Profile, select it in the Profile option at the top of the screen, if it isn't already selected. The Profile's settings will be displayed and you can make changes if you need to before you publish.
- If you have made changes to the structure of any of your Datasources, e.g. adding a new column or changing a column name, we recommend you take a backup of your existing database(s) before you publish the form and update the database(s). In addition, if you have changed any element mappings related to the amended Datasource, you will need to re-generate and save the Word template if you plan on using a form PDF. See the Create PDF Copies of Completed Forms topic for more details.
When you are ready to publish, use the Publish button at the bottom of the screen:
The Publish button generates the Client and Server files, creates the deployment package, creates/updates any required Digitise Forms databases and deploys the form(s) to the website, in accordance with the values in the currently selected Profile.
A progress bar will be displayed along with messages showing you the progress of the publish.
Form Studio will make various checks on your project, e.g. to check for changes to Datasources, and will display a list of warnings and errors if the checks generate any. If you have made changes to the structure of existing Datasources, e.g. adding or deleting columns, changing column names, changing whether a column can contain Nulls etc. the list will warn you about your changes and whether existing data may be at risk if you upgrade the existing databases. You will be asked to confirm that you want to make the changes. You can choose to upgrade the existing database, converting existing data if necessary, delete the current database and create a new one or abandon the publish. Invalid changes will prevent the form from being published.
- If when attempting to create a Digitise Forms database, the Digitise Forms Publisher is unable to log in to the specified SQL Server instance or the user specified doesn't have permissions to create the database(s), you will be given the opportunity to enter a different connection string using credentials which have the correct permissions. In the case of a failed login, you will be asked whether you want to save this new connection string, overwriting the original one. In the case of insufficient permissions, your new connection string is only temporary and will be deleted after using it to create the database(s).
- If an existing Digitise Forms database cannot be dropped before being recreated, you will be given the chance to close the existing connections and retry.
- With Digitise Forms Datasources, data is only stored in a database table when the database is created. If you later want to change the values stored, e.g. you want to add an extra item to a Check List or Radio List, you can do this in one of the following ways:
Delete the existing database and recreate it:
Edit the data in the appropriate Dataset and then change the name of the Dataset (see Create and Manage Datasets). The name change will automatically be applied to any relevant existing Element data mappings. Republish the form and Choose Drop and create new database when asked how you want your changes to be implemented.
This will delete the current database and create a new one, including storing your new data items. Since the original database will be deleted, any existing data in it, which won't be restored by your Datasource definitions, will be lost. We recommend, therefore, that you backup or extract the data before you make the changes.
If you want to retain the original name of the Dataset, you can rename the Dataset back to its original name and republish. This time, choose Upgrade existing data to apply your changes, as this will upgrade the existing database without deleting it.
- Edit the data outside Form Studio, e.g. using Microsoft's SQL Server Management Studio.
The first time you publish a form it may take a few minutes to complete all the stages and create any databases required. If you make changes to a form and republish it later, subsequent publishes will usually be quicker.
Once your form has been published successfully, you can then run it within a browser using the URL displayed in the Publishing Profile's URL field - see Forms category under Profile Settings above.
In order to publish your project you need to have Microsoft's Web Deploy tool installed on your development machine. The Digitise Forms install should have installed this, if it isn't already installed.
If you publish your project to your local machine, Digitise Forms will create the web application, specified in the Publishing Profile, in your local IIS, if it doesn't already exist. The web application will be created under the Default Application Pool with anonymous authentication. If the web application already exists, any changes you have made manually to its configuration will not be changed by Digitise Forms.
In order to deploy the form(s) to your specified website, the logged-in user must have read and write permissions for the following file:
C:\Windows\System32\inetsrv\config\applicationHost.config
and you may also need to set these permissions at the folder level, for the config folder containing this file. If you don't have suitable access rights to this folder and the applicationHost.config file, when you attempt to publish your form(s) you will get an error message saying you don't have the necessary permissions to create the local website application.
As an alternative way of avoiding this issue, you can load Form Studio using the Run as administrator option instead.
In order to publish your project you need to have Microsoft's Web Deploy tool installed on your development machine and on the remote web server - see beginning of this
In order to deploy the form(s) to your specified website, the IIS on the remote web site must be configured to allow you access - either using your current Windows credentials or IIS Manager User credentials. Within your Publishing Profile you must specify the correct authentication method in the Remote server publisher authentication option - see above for details.
In order to deploy the form(s) to your specified website, on the remote server the user under which the Web Deploy agent is running must have read and write permissions for the following file on that server:
C:\Windows\System32\inetsrv\config\applicationHost.config
You may also need to set these permissions at the folder level, for the config folder containing the file. If you don't have suitable access rights to this folder and the applicationHost.config file, when you attempt to publish your form(s) you will get an error message saying you don't have the necessary permissions to create the local website application.
If you are publishing your project to a remote web server, the publishing options allow you to specify whether you want to access the remote IIS using Windows Authentication or IIS Authentication (see above). The user you specify for these options would normally be the user who needs access permissions to the config folder and applicationHost.config file, unless you have configured the Web Deploy agent to run under a different user, in which case it will be that user who will need access.
If you want to configure your form to restrict access to users using Windows Authentication, you can do this within Internet Information Services (IIS) Manager. You will need to publish your form before you can configure it.
After you publish a form for the first time, load Internet Information Services (IIS) Manager on the web server.
Expand the tree view in the Connections pane on the left-hand side of the window.
Click on your web application in the tree to select it.
In the central pane, under the IIS category, double-click on the Authentication icon.
Find the Windows Authentication setting.
Check that it is set to Enabled, and if not, right-click on it and choose Enable from the menu displayed.
Find the Anonymous Authentication setting.
Check that it is set to Disabled, and if not, right-click on it and choose Disable from the menu displayed.
Select the web app in the Connections Pane again.
Double-click on the Configuration Editor icon, under the Management category in the central pane.
In the top left-hand corner of the central pane, immediately below the Configuration Editor title, you should see the Section drop-down.
Drop down the list and expand the system.web branch.
Click on authentication.
Set the mode option to Windows.
Choose Apply in the Actions Pane on the right-hand side of the window.
The mode setting is stored in a file called web.config located in the web app's root folder, e.g. C:\inetpub\wwwroot\BulkyWasteCollection\web.config.
If you subsequently republish the form, the web.config file will be overwritten with a new version which will reset the authentication mode setting back to None. Consequently you will need to reconfigure this setting in IIS Manager after every publish. You shouldn't need to reset the setting under the Authentication icon, only under the Configuration Editor.
For more information about configuring Windows Authentication in IIS Manager refer to the help available within IIS Manager or Microsoft's web site.
You can check when a project was last published by looking in the Info section available from the File Menu.